Everything about Atari Basic totally explained
» For the version of BASIC bundled with the Atari ST computer series, see Atari ST BASIC.
ATARI BASIC is a
ROM resident
BASIC interpreter for the
Atari 8-bit family of
6502-based
home computers. The interpreter originally shipped on an 8
KB cartridge; on later XL/XE model computers it was built in, and would load by default when the machines were
booted without other carts in place. The complete commented
source code and design specifications of ATARI BASIC had been published early as a book. This marked the first time source code was made available for a commercial language.
Background
The machines that would become the
Atari 8-bit family had originally been developed as a second-generation
games console intended to replace the
Atari 2600. Ray Kassar, the then-new president of Atari, decided to challenge
Apple Computer by building a home computer instead. This meant Atari needed the
BASIC programming language, then the standard language for most home computers.
Atari did what many of the other home computer companies did: they purchased the
source code to the
MOS 6502 version of
Microsoft 8K BASIC with the intent to
port it to run on the new machines. The name was something of a misnomer, however, as the 8K referred to its original size on the
Intel 8080's
instruction set. On the 6502's "less dense" instruction set the language was somewhat larger, over 11K. Atari had designed their ROM layout in 8 kB blocks, and paring down the code from 11 to 8 kB turned out to be a significant problem. Adding to the problem was the fact that the 6502 code supplied by Microsoft was basically undocumented.
Six months later, they were almost ready. But Atari had a deadline with the
Consumer Electronics Show (CES) approaching and decided to ask for help.
Shepardson Microsystems
In September
1978 Atari asked
Shepardson Microsystems (SMI) to bid on completing BASIC. Shepardson had written a number of programs for the 6502-based
Apple II, and were in the midst of finishing a new advanced BASIC for the
Cromemco S-100 bus machines (Cromemco 32K Structured BASIC). SMI examined the existing work and decided it was too difficult to continue paring it down; instead they recommended developing a completely new version that would be easier to fit into 8 kB. Atari accepted the proposal, and when the specifications were finalized in October 1978, Paul Laughton and Kathleen O'Brien began work on the new language.
The result was a rather different version of BASIC, known as
ATARI BASIC. In particular, the new BASIC featured string handling very different than Microsoft's version, patterned like
Data General's BASIC rather than MS's version which used strings similar to those from
DEC BASIC.
The contract specified a delivery date by April 6, 1979 and this also included a File Manager System (later known as DOS 1.0). Atari's plans were to take an early 8K version of Microsoft BASIC to the 1979 CES and then switch to the new Atari BASIC for production. Thanks to a bonus clause in the contract, development proceeded quickly and an 8K cartridge was available just before the release of the machines. Because of the speed in getting Atari BASIC, Atari ended up taking it to CES instead of the pre-production Microsoft BASIC.
Shepardson's programmers found bugs in the first-pass review and managed to fix some of them, but Atari had already committed BASIC to manufacturing. This initial buggy version became known as
Revision A.
- Revision A - First Atari BASIC cartridge. 8kB ROM.
- Revision B - Fixed all of the major bugs in Revision A, but introduced a leaking memory bug. Found built-in on the 600XL and early 800XLs. No cartridges.
- Revision C - Eliminated memory leak in Revision B. Found on later 800XLs, the 800XLF, XEGS and all XE computers. Limited cartridge production run.
Description
Program editing
Atari BASIC used a line-oriented editor, in common with most BASICs of the era. Unlike many BASICs, however, Atari BASIC immediately checked the line for
syntax errors. If a problem was found it re-printed the line, highlighting the text near the error. This made catching errors on the Atari much easier, as most BASICs wouldn't display most errors until the program was later
RUN, when the new line would no longer be fresh in the author's mind.
When not running a program, Atari BASIC is in
intermediate mode, where lines can be entered (with a line-number) or immediate commands can be entered (without a line-number) that are executed immediately. Unlike most other BASICs, however, Atari BASIC allowed
any command to be executed in either immediate mode or within a program. For instance most BASICs would allow
LIST to be used only in immediate mode, while Atari BASIC would also allow it to be used inside a program.
The tokenizer
Like most BASIC interpreters, Atari BASIC used a token structure to handle
lexical processing for better performance and reduced memory size. The
tokenizer converted lines using a small buffer in memory as a scratchpad. The token output buffer (LOMEM - 80, 81
16) was 256 bytes in size, any tokenized statement that was larger than the buffer would generate an error (14 - line too long).
The output from the tokenizer was then moved into more permanent storage in various locations in memory. Variables were stored in the
variable name table (VNTP - 82, 83
16) and the values were stored in the
variable value table (VVTP - 86, 87
16). Strings had their own area (STARP - 8C, 8D
16) as did the runtime stack (RUNSTK - 8E, 8F
16). Finally, the end of BASIC memory usage was indicated by the MEMTOP (90, 91
16) pointer.
Atari BASIC used a unique system for abbreviating reserved words. Unlike MS BASIC where there were a few "pre-rolled" short forms,
? for
PRINT and
' for
REM for instance, Atari BASIC allowed any word to be typed in using a period, more like written English. For instance,
L. would be expanded to
LIST. To expand an abbreviation the tokenizer would search through its library of reserved words (see below) and stopped at the first one that matched. In order to make the abbreviations "work" properly, the list of reserved words was sorted to place the most commonly used commands closer to the top of the stack.
REM was placed at the very top of the stack, and could be typed in as
.. It should be noted that the MS solution used separate tokens for their (few) short forms, whereas Atari BASIC had only one token for any possible short form of
PRINT (
PL.,
PR.), and when the program was later
LISTed it would always write out the "real" expanded form.
There was a single exception to this. While the official abbreviation for
PRINT was
PR. you could also use a
?. And this had a separate token, hence would remain in a program listing.
The expanding of tokens in the listing could cause a problem when editing a program. The Atari line input buffer was 3 screen lines (120 characters). But using abbreviations when typing in a line could result in an expanded line that was significantly longer than 120 characters. If you then wanted to edit the line, you'd need to replace the expanded commands with their abbreviations, otherwise it wouldn't be accepted.
Additionally, line numbers found in commands were calculated at runtime using the same math routines as other BASIC functions. This calculation allowed routines to be referred to by variables, for instance
GOTO EXITOUT, as long as one remembered to initialize
EXITOUT sometime prior. This was much more useful than it might sound; tokenized variables were stored in a six-byte format only once in memory, whereas explicit line numbers took up a byte for every digit in the number every time it appeared in the program. If many parts of a program jumped to a single line number, which is fairly common in BASIC, replacing the explicit line numbers with variables could save considerable amounts of memory.
String handling
Atari BASIC differs dramatically from Microsoft-style BASICs in the way it handles strings. In MS-like BASICs, strings are special types that allow for variable length and various operations. Atari BASIC has no strings of this sort, instead using
arrays of characters. This allowed the programmers to remove all the special-purpose code needed for strings, replacing it with the code already being used to handle arrays of numbers.
Of course, strings are not
used in the same fashion as arrays of numbers—at least not normally—so Atari BASIC also included a selection of commands for "slicing" up arrays.
A$ referred to the entire string, whereas
A$(4,6) "sliced" out the three characters 4, 5 and 6. In theory, this was a more elegant solution than MS BASIC's
LEFT$,
MID$, and
RIGHT$ solution, as this syntax replaces three separate commands with a single one.
Although this simplification reduced the size of Atari BASIC and offered some theoretical performance benefits, it also made it much more difficult to port BASIC programs onto the Atari, arguably more so than any other difference. Users would have to scan programs for instances of
LEFT$, et al., and replace them with slicing commands.
Strings in Atari BASIC were limited to one-dimensional arrays, so arrays of strings had to be implemented by the programmer. According to Bill Wilkinson, a programmer at SMI, the decision to go with strings larger than 255 characters in size made string arrays unfeasible.
Input/Output
The Atari
operating system included routines for device input/output known as CIO (Central Input/Output). Atari BASIC supported CIO access with reserved words
OPEN, CLOSE, PRINT, INPUT, GET, PUT, and XIO.
The I/O channels in the OS were known as
Input/Output Control Blocks (IOCB). The BASIC
OPEN command was used to open devices for I/O access.
Example: Opens the cassette device on channel 1 for reading in BASIC
OPEN #1,4,0,"C:"
There were eight IOCBs in total, but a number of them were reserved. IOCB 0 was for the screen editor and couldn't be accessed from BASIC. IOCB 7 was used by built in BASIC commands for I/O (eg LPRINT, SAVE, LOAD, CSAVE, CLOAD). IOCB 6 was used for accessing the Graphics device in Graphics mode. Common devices were C: for the cassette, D: for disks, P: for printers and so on.
SAVE and
LOAD outputted the tokenized form of the BASIC program,
LIST and
ENTER the text source.
For the other CIO functions, BASIC uses the
XIO statement for access. This included screen functions, serial (RS-232) functions as well as disk operations like format or deleting a file.
Example: Fill command in BASIC
XIO 18,#6,12,0,"S:"
Hardware support
Other features of ATARI BASIC, in comparison to the BASICs of some competing machines at the time, were its built-in support of sound and high-resolution graphics (
SOUND, GRAPHICS, SETCOLOR, COLOR, PLOT and
DRAWTO) as well as peripheral units like joysticks (
STICK, STRIG) and paddles (
PADDLE, PTRIG). Other home computer users were often left with cryptic
POKE's for such programming.
Performance
Atari BASIC was slower than other BASICs, sometimes by a surprising amount given the higher speeds of the underlying hardware. Most of these problems stemmed from two particularly poorly implemented bits of code.
One was a side-effect of the way that Atari BASIC re-calculated line numbers as the program was being run. This meant that a
GOTO had to run a small amount of additional code in order to find the line to jump to. This would normally be a minor issue, but the same code was also used to implement the "reverse jump" at the end of
FOR...
NEXT loops, dramatically lowering overall performance of these very common structures.
Atari BASIC also didn't support integer variables, all numeric operations and numeric values were in floating point. Atari BASIC relied on the Atari OS's built-in floating point routines (BCD notation), which were slow. Most of this was due to a particularly poor implementation of the multiply code that was used throughout the math libraries. This was arguably not a problem of the language itself but the underlying OS, but it added to the general poor performance.
Several commercial and shareware BASICs were available on the platform that addressed some or all of these issues, resulting in performance that was 3 to 5 times faster than the Atari version. Using these BASICs, the Atari was one of the fastest home computers of its era.
Atari later sold a
diskette-based version of MS BASIC,
Atari Microsoft BASIC, and later managed to fit it onto a cartridge as well, but no compiler or runtime was available for redistribution.
Advanced techniques
Despite its small footprint (8k), Atari BASIC had some features that gave it some powers of more-advanced versions of BASIC.
Functions
Atari BASIC had no implementation of user functions. However, programmers could simulate user functions because of the way the GOSUB command could reference a variable. For example, a programmer could start a subroutine at line 10000 and have the program initialize a variable with that number, for example "TEST = 10000". When that subroutine was needed the program could load some predetermined variables then use the command "GOSUB TEST". The subroutine at line 10000 would do its operation on the predetermined variables and could put a return result in another predetermined variable.
Includes
Atari BASIC could import lines of code and merge them into a single program as long as the line numbers didn't conflict. By careful use of non-conflicting line numbers programmers could build libraries of subroutines (simulating functions as above) and merge them into new programs as needed.
Embedded machine language
String variables could hold any of the 256 characters available in the
ATASCII character set and thus each byte of memory reserved for a string variable could hold any number from 0 to 255. Short 6502 machine language routines could be converted to ATASCII characters and stored as a string variable. The machine language routine could be called as a function with the USR command specifying the address of the string variable as the location in memory to execute. For example, if the machine language code was stored in a variable named ROUTINE$ it could be called and parameters passed to it with the following command: "ANSWER=USR(ADR(ROUTINE$),VAR1,VAR2)". Such routines had to be relocatable (no jump commands, only branch-type jumps) because the actual location in memory was unpredictable.
Reserved words
ABS DRAWTO NEW RESTORE VAL
ADR END NEXT RETURN XIO
AND ENTER NOT RND
ASC EXP NOTE RUN
ATN FOR ON SAVE
BYE FRE OPEN SETCOLOR
CLOAD GET OR SGN
CHR$ GOSUB PADDLE SIN
CLOG GOTO PEEK SOUND
CLOSE GRAPHICS PLOT SQR
CLR IF POINT STATUS
COLOR INPUT POKE STEP
COM INT POP STICK
CONT LEN POSITION STRIG
COS LET PRINT STOP
CSAVE LIST PTRIG STR$
DATA LOAD PUT THEN
DEG LOCATE RAD TO
DIM LOG READ TRAP
DOS LPRINT REM USR
Further Information
Get more info on 'Atari Basic'.
|
External Link Exchanges
Do you know how hard it is to get a link from a large encyclopaedia? Well we're different and will prove it. To get a link from us just add the following HTML to your site on a relevant page:
<a href="http://atari_basic.totallyexplained.com">Atari BASIC Totally Explained</a>
Then simply click through this link from your web page. Our crawlers will verify your link, extract the title of your web page and instantly add a link back to it. If you like you can remove the words Totally Explained and embed the link in article text.
As long as your link remains in place, we'll keep our link to you right here. Please play fair - our crawlers are watching. Your site must be closely related to this one's topic. Any kind of spamming, dubious practises or removing the link will result in your link from us being dropped and, potentially, your whole site being banned. |
